Artificially Intelligent Computing Engine for Travel Itinerary Resolutions

ABSTRACT

Systems and methods for fulfilling travel requests are described herein. A method for fulfilling travel requests may commence with receiving a travel request from a user and determining itinerary components based on the travel request. The method may further include generating an itinerary network based on the itinerary components. The itinerary network may be generated by creating a plurality of nodes and creating a plurality of edges within the itinerary network. Each of the plurality of nodes may represent information associated with the travel request. The plurality of edges may represent an order of the plurality of nodes in time based on dependencies between the plurality of nodes. The method may further include generating a travel itinerary responsive to the travel request. The method may continue with presenting the generated travel itinerary to the user on a user interface of a computing device associated with the user.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. non-provisional patentapplication Ser. No. 16/396,487, filed Apr. 26, 2019, which claims thepriority benefit of U.S. provisional patent application No. 62/747,088,filed Oct. 18, 2017 and is a Continuation-in-part and claims thepriority benefit of U.S. non-provisional patent application Ser. No.13/420,179, filed Mar. 14, 2012, which in turn claims the prioritybenefit of U.S. provisional patent application Ser. No. 61/452,633,filed Mar. 14, 2011. The present application also claims the prioritybenefit of U.S. provisional patent application Ser. No. 62/747,088 filedon Oct. 17, 2018.

U.S. non-provisional patent application Ser. No. 13/420,179, filed Mar.14, 2012 is related to the Applicants' co-pending U.S. non-provisionalpatent application Ser. No. 13/419,989, filed Mar. 14, 2012 and issuedMar. 15, 2016, as U.S. Pat. No. 9,286,629, and to the Applicants'co-pending U.S. non-provisional patent application Ser. No. 13/420,433,filed Mar. 14, 2012 and issued Sep. 18, 2018, as U.S. Pat. No.10,078,855. All of the above referenced applications are herebyincorporated by reference herein in their entirety.

FIELD OF THE PRESENT TECHNOLOGY

The present technology relates generally to the processing andfulfilling of natural language travel requests, and more specifically,but not by way of limitation, to an exchange that allows suppliers toprovide inventory records and customers to input travel itineraryrequests in a natural language format, and fulfills the travel itineraryrequests by applying pattern recognition artificial intelligence and/orsemantic parsing to inventory records and travel itinerary requests toobtain matches therebetween.

BACKGROUND

The ability to sell more inventory/content, sell current inventory moreefficiently, and to differentiate product is extremely important andurgent to suppliers, especially in the travel and hospitalityindustries. Additionally, consumers want and need more choice andinventory/content. The current legacy supply chain for fulfilling travelrelated needs of consumers is complicated and remains under the controlof various companies, most of which directly or indirectly compete withone another. Even if those within the supply chain are not hindered fromcooperating by competition, the division of services/responsibilitieswithin a single supplier may further hinder these legacy supply chains.For example, with respect to an airline, current inventory may bemaintained by one entity or department while flights are managed byanother department and/or business. Moreover, airline rules and pricingmay be managed by yet another department and/or business. Businessprocesses that interact with these legacy systems must be structured tocorrespond to these entities and their rules. For each entity, acompletely different set of requirements may be imposed upon businessprocesses that depend upon these entities. In sum, the structures ofthese legacy supply chain systems make it extremely difficult, if notimpractical, to properly aggregate offerings and/or add newinventory/content that would be recognized and accepted by the legacysystems.

Furthermore, conventional artificial intelligence engines available inthe market use of a posteriori artificial intelligence that is entirelydependent on data and experience and, hence, requires large amounts ofresources to collect data and analyze experience.

SUMMARY OF THE PRESENT TECHNOLOGY

This disclosure is directed to systems and methods or fulfilling travelrequests. According to some embodiments, a method for fulfilling travelrequests may commence with receiving a travel request from a user anddetermining itinerary components based on the travel request. The methodmay further include generating an itinerary network based on theitinerary components. The itinerary network may be generated by creatinga plurality of nodes and creating a plurality of edges within theitinerary network. Each of the plurality of nodes may representinformation associated with the travel request. Each of the plurality ofedges may connect two of the plurality of nodes. The plurality of edgesmay represent an order of the plurality of nodes in time based ondependencies between the plurality of nodes. The method may furtherinclude generating a travel itinerary responsive to the travel request.The travel itinerary may be consistent with the itinerary network. Themethod may continue with presenting the generated travel itinerary tothe user on a user interface of a computing device associated with theuser.

According to other embodiments, the present technology may be directedto a system for fulfilling travel requests. The system may include amemory for storing executable instructions, a processor for executingthe instructions, and a parser stored in the memory and executable bythe processor. The parser may be configured to receive a travel requestfrom a user and determine itinerary components based on the travelrequest. The parser may be further configured to generate an itinerarynetwork by creating a plurality of nodes within the itinerary networkand creating a plurality of edges within the itinerary network. Each ofthe plurality of nodes may represent information associated with thetravel request. Each of the plurality of edges may connect two of theplurality of nodes. The plurality of edges may represent an order of theplurality of nodes in time based on dependencies between the pluralityof nodes. The parser may be further configured to generate a travelitinerary responsive to the travel request. The travel itinerary may beconsistent with the itinerary network. The parser may be furtherconfigured to present the generated travel itinerary to the user on auser interface of a computing device associated with the user.

BRIEF DESCRIPTION OF THE DRAWINGS

Certain embodiments of the present technology are illustrated by theaccompanying figures. It will be understood that the figures are notnecessarily to scale and that details not necessary for an understandingof the technology or that render other details difficult to perceive maybe omitted. It will be understood that the technology is not necessarilylimited to the particular embodiments illustrated herein.

FIG. 1 illustrates an exemplary architecture for practicing aspects ofthe present technology.

FIG. 2 illustrates an exemplary itinerary processing system, constructedin accordance with the present technology.

FIG. 3 illustrates flow diagram of events through an exchange system.

FIG. 4 illustrates a flow diagram on an exemplary method for processingnatural language travel requests.

FIG. 5 illustrates an exemplary method for notifying suppliers of anatural language travel request.

FIG. 6 illustrates an exemplary flow diagram of a process for fulfillinga schedule.

FIG. 7 shows an itinerary network, according to an example embodiment.

FIG. 8 shows a sub-path of nodes of an itinerary network, according toan example embodiment.

FIG. 9 shows a parser network as a cover for travel conversations,according to an example embodiment.

FIG. 10 shows an itinerary network, according to an example embodiment.

FIG. 11 is a block diagram of an exemplary computing system forimplementing embodiments of the present technology.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

While this technology is susceptible of embodiment in many differentforms, there is shown in the drawings and will herein be described indetail several specific embodiments with the understanding that thepresent disclosure is to be considered as an exemplification of theprinciples of the technology and is not intended to limit the technologyto the embodiments illustrated.

It will be understood that like or analogous elements and/or components,referred to herein, may be identified throughout the drawings with likereference characters. It will be further understood that several of thefigures are merely schematic representations of the present technology.As such, some of the components may have been distorted from theiractual scale for pictorial clarity.

Generally speaking, the present technology comprises systems, methods,and media for processing natural language travel requests. Morespecifically, but not by limitation, the present technology may fulfilltravel requests in the form of natural language expressions of a travelitinerary. An artificial intelligence engine used in methods and systemsof the present disclosure may act as a priori artificial intelligenceengine (i.e., may assume an a priori knowledge of certain structures).The present technology provides an efficient and simplified supply chainfor the addition, organization, and consumption of inventory, togetherwith a simplified distribution model. Additionally, the systems providedherein may also interact seamlessly with, and coexist with, legacysystems.

Advantageously, the present technology provides increased efficiency andcapabilities, allowing access to greater amounts of content that may beutilized to fulfill natural language travel requests. Unlike mostsystems or search engines, where a URL is provided as a solution or afew thousand options for a single request or a component of a request,the preset technology provides coherent solution(s) for natural languagetravel requests.

Additionally, the present technology may be implemented within thecontext of an exchange system that allows suppliers to provide inventoryrecords and customers to input travel itinerary requests in a naturallanguage format and fulfills the travel itinerary requests by applyingpattern recognition artificial intelligence and/or semantic parsing toinventory records and travel itinerary requests to obtain matchestherebetween.

Referring to the collective drawings (e.g., FIGS. 1-11 ), the presenttechnology may facilitate an exchange that fulfills natural languagetravel requests. The present technology may be implemented within thecontext of an exemplary architecture 100, hereinafter “architecture 100”as shown in FIG. 1 . The architecture 100 may be described as generallyincluding an exchange 105 (also referred to herein as exchange system105). Consumers 110 and third party suppliers 115 may communicate witheither the exchange 105, via a network 120. It is noteworthy to mentionthat the network 120 may include any one (or combination) of private orpublic communications networks such as the Internet. The consumers 110may interact with the exchange 105 via end user client devices thataccess a web based interface or an application resident on the end userclient device.

In some embodiments, the third party suppliers 115 may communicativelycouple with the exchange 105 over the network 120 via an applicationprogramming interface (API). It is noteworthy that other methods/systemsthat allow the third party suppliers 115 and the exchange 105 tocommunicatively couple with one another, that would be known to one orordinary skill in the art, are likewise contemplated for use inaccordance with the present disclosure.

For the purposes of brevity and clarity, certain functional and/orstructural aspects of the exchange 105 will be described in greaterdetail herein. More specifically, but not by way of limitation, thepresent disclosure will address the processing and fulfillment ofnatural language travel requests. Additional details regarding theexchange 105 may be found in co-pending U.S. non-provisional patentapplication Ser. No. 13/420,433, filed Mar. 14, 2012 and issued Sep. 18,2018, as U.S. Pat. No. 10,078,855, which is hereby incorporated byreference herein in its entirety.

According to some embodiments, the exchange 105 may include a cloudbased computing environment. In general, a cloud-based computingenvironment is a resource that typically combines the computationalpower of a large grouping of processors and/or that combines the storagecapacity of a large grouping of computer memories or storage devices.For example, systems that provide a cloud resource may be utilizedexclusively by their owners, such as Google™ or Yahoo!™; or such systemsmay be accessible to outside users who deploy applications within thecomputing infrastructure to obtain the benefit of large computational orstorage resources.

The cloud may be formed, for example, by a network of web servers, witheach web server (or at least a plurality thereof) providing processorand/or storage resources. These servers may manage workloads provided bymultiple users (e.g., cloud resource consumers or other users).Typically, each user places workload demands upon the cloud that vary inreal-time, sometimes dramatically. The nature and extent of thesevariations typically depend on the type of business associated with theuser.

The exchange 105 may be generally described as a particular purposecomputing environment that includes executable instructions that areconfigured to receive and fulfill natural language requests, such astravel itinerary requests.

In some embodiments, the exchange 105 may include executableinstructions in the form of an itinerary processing and fulfillmentapplication, hereinafter referred to as “application 200,” “a system forfulfilling travel requests,” or “a system.” The application providesvarious functionalities that will be described in greater detail herein.FIG. 2 illustrates and exemplary schematic diagram of the application200.

The application 200 is shown as generally comprising components such asa semantic parsing module, hereinafter referred to “a parser” or“parsing module 205,” a pattern recognition artificial intelligenceengine, hereinafter “AI engine 210,” a scheduling module 215 (alsoreferred to herein as scheduling module 215), and a modification module220. It is noteworthy that the application 200 may include additionalmodules, engines, or components, and still fall within the scope of thepresent technology. As used herein, the terms “module” and “engine” mayalso refer to any of an application-specific integrated circuit (ASIC),an electronic circuit, a processor (shared, dedicated, or group) thatexecutes one or more software or firmware programs, a combinationallogic circuit, and/or other suitable components that provide thedescribed functionality. In other embodiments, individual components ofthe application 200 may include separately configured web servers.

FIG. 3 includes an exemplary flow diagram that illustrates the flow ofdata from a publishing environment into an exchange, along with thereceipt of natural language travel requests and their fulfillment. Whilefunctional details regarding how the exchange 105 processes and fulfillsnatural language travel requests will be described with reference toadditional figures described below (e.g., FIGS. 4-6 ), the overalloperational flow of the exchange system 105 is shown in FIG. 3 .

Referring now to FIGS. 2 and 4 collectively, the scheduler module 215may utilize the parsing module 205 to interpret the natural languagequeries. FIG. 4 illustrates a flowchart of an exemplary method forprocessing natural language travel requests.

According to some embodiments, the parsing module 205 may assume an apriori knowledge of certain structures and intent over a class ofinformation (for example, the hospitality and travel space).

Initially, it is noteworthy to mention that the natural language travelrequests received by the parsing module 205 may comprise a textualrequest, a spoken (e.g., audio format) request, a location basedrequest, an input based request (e.g., a click of an object on a map), aglobal positioning signal, and/or any combinations thereof. Moreover, insome instances, the request may comprise a non-natural language request,such as a keyword request, a Boolean phrase, and so forth.

In this sense, the information requested by the end user in naturallanguage may not be parsed by the parsing module 205 for grammar in thesense that a normal parser would operate. Rather, the parsing module 205may infer a pre-determined set of information through a patternrecognition artificial intelligence module, such as the AI engine 210.

More specifically, the parsing module 205 may first (Step 405) delimitthe natural language query. For example, the parsing module 205 maydetermine inventory components in the query.

The parsing module 205 may parse through each delimited string (Step410) and transmit the delimited strings to the AI engine 210.

The AI engine 210 may act as an a priori AI engine (i.e., may assume ana priori knowledge of certain structures). While the a priori AI engineis discussed herein in terms of its application to travel, a person ofordinary skill in the art would understand that the engine can besimilarly utilized in any domain.

The a priori AI engine does not use evidentiary data required for theformulation of the AI. The knowledge and understanding have to existbefore any data is provided. This is in stark contrast to current AIengines in the market, which use a posteriori AI that is more commonlyprevalent and is entirely dependent on data and experience.

The AI required for the a priori AI engine cannot be ascertained fromthe interaction between users and the system. Much of the intelligenceis knowledge and understanding that is not part of this interaction butis contained in the structures and morphology behind the interface. Thetotality of the understanding of requests by the a priori AI engine isnot contained within the conversation with a user.

The a priori AI engine cannot be reduced to a set of rules. This maymake the system entirely deterministic, which it is not, and may requirethe system to consider so many cases that it can be practically infinitein size.

Additionally, in a rule-based system, a rule must be given for everycase. In any non-trivial system, it is not possible to cover everypotential scenario that may occur, as per Gödel's incompletenesstheorem. In the a priori AI engine, the AI can ascertain the rule,intention, and action for all cases.

It is asserted that concepts are known and understood first and thatlanguage evolves to describe these concepts. Consequently, we do notbegin with language at all, but rather, we imbue the system with anunderstanding of travel logistics.

The a priori AI engine may essentially deal with the conversationitself, not just the content of the conversation. Thus, eachconversation initiated by either the user or the system may have anumber of essential parts. Specifically, the conversation may have anobjective or goal. For example, the objective may be the building ormodification of an itinerary. The objective may be a response from theuser to a question posed by the system to the user dealing with errors,or the like. Furthermore, each of the conversations may have a state,such as awaiting answer, completed, and the like. As would be understoodby a person of ordinary skill in the art, many types of conversationscan exist at the same time for a given user.

The AI engine 210 may employ a combination of phraseology and keywordinference (Step 415) to decode what type of request is being made.Specifically, the AI engine 210 may determine the itinerary componentsby decoding the itinerary components from the travel request bydetermining phrases and tokens of the travel request. The AI engine 210may reference the metadata database and the equivalence class database.Keywords included in an AI pattern recognition database may direct theAI engine 210 to appropriate content categories for the itinerarycomponents included in the request (Step 420). The AI engine 210 mayemploy additional inferential methods as well as statistical methods andfrequency to determine where and how to match content to the request.

The parsing module 205 may evaluate each word of the sentence. If nokeywords are found, nothing is constructed. However, the AI engine 210may employ a “similar to” inference functionality which allows forvariation among the phraseology to account for different ways thatnatural language queries may be structured such as incorrect spelling,grammar, and similar contingencies.

Once the parsing module 205 has determined the itinerary componentsincluded in the natural language travel request, the parsing module 205determines a node type for each of the itinerary components andascertain dependencies between each of the itinerary components basedupon respective node types. It will be understood that the parsingmodule may effectuate construction of itineraries in a variety ofmanners. For example, the parsing module 205 may parse the words of therequest in a sequential manner. The parsing module 205 may also parsethe request to determine categories of itinerary components included inthe request. In other instances, the parsing module 205 may delimit therequest.

The method for fulfilling travel requests of the present disclosureutilizes an itinerary network graph with nodes and dependencies.Specifically, according to some embodiments, the parsing module 205 mayutilize a directed acyclic graph (DAG), also referred to as an“itinerary network,” to interpret natural language queries. Theinformation extracted by the parsing module 205 may be utilized togenerate an itinerary network that provides a further dynamicintelligence to the parsing module 205 in understanding the requested,parsed information, and assist the parsing module 205 in determiningpossible logical and logistics connections (e.g., location, time, andtraveler preference based dependencies). Therefore, the parsing module205 may generate the itinerary network based on the itinerary componentsof the travel request. Specifically, the parsing module 205 may create aplurality of nodes within the itinerary network. Each of the pluralityof nodes may represent information associated with the travel request.The parsing module 205 may further create a plurality of edges withinthe itinerary network. Each of the plurality of edges may connect two ofthe plurality of nodes. The plurality of edges may represent an order ofthe plurality of nodes in time based on dependencies between theplurality of nodes.

The parsing module 205 may generate a travel itinerary responsive to thetravel request. The travel itinerary may be consistent with theitinerary network. The parsing module 205 may present the generatedtravel itinerary to the user on a user interface of a computing deviceassociated with the user.

The nodes may be of different types and may store information about theitinerary. The nodes may represent cities, hotels, flights, anddestination content (such as a concert or car rental). The nodes cancontain information specific to the type of node. For instance, a citynode may contain an airport, whereas a flight node may contain the classof service.

Edges connect nodes to show dependencies between nodes and may containinformation themselves. The edges are directed to represent the order ofnodes in time. In one example embodiment, edges can be air transport,car transport, start to start, or start to finish. In other words, theedges can present information that may be important when scheduling theitinerary.

If a user expresses a desire to travel between two cities, an itinerarynetwork can be used to represent this travel request of the user. Tocreate the itinerary network, two city nodes may be created first: onefor the source city and one for the destination city expressed by theuser. The city nodes may be populated with the names of the cities inthe user request and possibly names of airports. Then, these cities maybe connected with a directed edge (dependency). The edge may containinformation for a flight, rail, bus, or other mode of transport betweenthe two cities, as well as other information, such as the schedulingtype. In some cases, for example, in multi-passenger scenarios andsituations where dependencies between passengers arise, the mode oftransport may be presented as the node type and may be further qualifiedin the dependencies between the city and the transport node.

If the same user expresses a desire to travel between two city pairs,this process may be done twice. It may be incorrect logistically andlogically to put one person on two flights departing at the same time.In view of this, the first condition is that each passenger must have apath-connected graph. The second condition is that the graph is acyclic.The a priori AI engine understands that the itinerary network is acompact path connected topological space, with all the mathematicaltools and theorems that follow from that at disposal of the a priori AIengine. This allows the AI to fully understand the properties of theitinerary network and to know if the path connectedness property isbroken and how to resolve it by communication with the user. Thisunderstanding is naturally inherent within the systems and the methodsof the present disclosure and it has been built into the a priori AIengine.

The itinerary network provides a coherent consistent entity that canthen be treated by a scheduler for scheduling of a travel request. Morethan this, the systems and the methods of the present disclosure coverevery case one could glean from data or experience, without having toinput a multitude of individual rules to teach the a priori AI engine.

The resultant itinerary network contains all of the informationnecessary for the system to supply congruent content (logistic andcurated data). The characteristics of the itinerary are thecharacteristics of a path-connected, directed acyclic, compacttopological space or combinations of such spaces. This provides thecapability of scheduling the itinerary in a consistent and coherentmanner. It also allows the parser to understand all the aspects of theitinerary.

The itinerary network may describe the itinerary, such as flights,hotels, cars, events, reservations, and other disparate content. Theitinerary network also describes the temporal and dependentrelationships of the passengers and their content. The understanding ofthe itinerary depends on the scheduler, which instantaneouslyunderstands the logistics and content of the network. The parser may beimbued with the lexicon and capabilities of the itinerary network and assuch can understand and interact with the itinerary networkindependently or through conversations with the user.

All of these described elements are part of the a priori AI enginedirected to not simply understanding language. In fact, the language isan insufficient condition to the AI of the system. The a priori AIengine may inform what language is to be understood and what language isnot relevant.

Goal Orientation—Seeking. The a priori AI engine may use the parser, thescheduler, and so forth, to seek to fulfill an itinerary request. Forthis purpose, the a priori AI engine may build an itinerary network andschedule the itinerary network with appropriate curated content. Theparser may use the tree of nodes (parser trees) to address anyconversation that seeks to instruct the system to build or modify anyitinerary.

In some instances, itinerary components may comprise travel ornon-travel node types. For travel node types, the parsing module 205 mayobtain source and destination information from relevant itinerarycomponents (Steps 425 and 430). If they do not exist on the itinerarynetwork, the parsing module 205 may add them to the itinerary network.For non-travel nodes, the parsing module 205 may determine if the nodehas a time or location dependency to another node (Step 435). If thenode does have a dependency, the parsing module 205 checks to see if thedependent node exists. If it does not, the parsing module 205 willcreate the node and populate the node with any necessary attributes(Step 440).

According to some embodiments, the parsing module may also identifytraveler preferences. Traveler preferences can include general orspecific preferences and are requested or ordered in natural language.Some examples include: “give me cheapest flight,” “do not book me intoany Hilton hotels,” “provide me four-star hotels or better,” and “If Iam in San Francisco book me into the San Mateo Sofitel hotel.”

The process of identifying nodes for itinerary components andinterrelating these nodes may be referred to as generating an itinerarynetwork. The itinerary network may be utilized by the scheduler module215 to generate an unconstrained schedule for the natural languagerequest, as will be described in greater detail herein.

The characteristics of an itinerary may include a stage, a state, and acontext. These characteristics allow the parser to be sentient in theconversation with the user through the life cycle of the itinerary (pre-to post-booking and change management) and partial completion of theitinerary. The sentience includes understanding the meaning of therequest (based on from context, stage and state). The goal orientationof the system may be to serve an itinerary request. The stage mayinclude a pre-booking state and a post-booking stage. The stage isimportant for establishing the context, as well as for communicatingrelevant information to a user, such as change and cancellation fees orother disruptions to the itinerary as a result of a change or delay.

The state is broadly defined by two elements, namely the itinerarynetwork and the conversation. The state includes determining, forexample, whether the system is conversing with the user about theitinerary, whether the user has booked a trip, whether there are flagson the itinerary that need to be addressed (such as incompleteinformation or infeasible solution), and so forth.

Context may be built into an itinerary object. This may providesentience to the AI engine as the AI engine interprets new requests orchanges for the itinerary. The context may be dynamic as the itineraryobject changes its stage, state and topology. As one can easily see,traditional machine learned artificial intelligence simply cannot copewith dynamic context because the number of experiences is an NP-Completedecision problem, even a higher order of complexity than NP-Harddecision problem.

It should be noted that all of the machine learning/neural network typeprocesses around natural language by their construction must infer thesemantic meaning from language data that is input into the neuralnetwork and trained on the semantic meaning. In “The Language ComplexityGame (Artificial Intelligence)” by Eric Ristad, The MIT Press; FirstEdition (Mar. 17, 1993), it is argued that language is the process ofconstructing linguistic representations from the forms produced by othercognitive modules and that this process is NP-complete. However, neuralnetworks and other statistical-based inference models as a technology donot rise to the complexity class required to solve NP-complete problems.It is undeniable that they can make inferences with some accuracy, e.g.,when being shown one million examples of a number 5, the neural networksand other statistical-based inference models will pick a 5 out 99% ofthe time correctly when shown numbers. When noise is introduced into theneural networks, the neural networks may still infer, with the sameconfidence, that a static page before a user is a number 2. When beingasked by a user to draw a 5, the neural networks cannot answer the user.Thus, the structure of conventional neural networks is incapable ofdoing anything other than returning a probability.

The a priori AI engine described herein changes the problems complexityclass from NP-complete to order kN. The a priori AI engine is imbuedwith knowledge of travel, and language does not need to be inferred,language needs only be matched as the set of language patterns aregenerated by the capabilities and understandings of the underlyingmorphology/referential framework. In this sense, the behavior of the apriori AI engine is totally unique in the ecosystem of natural languagehuman machine interfaces.

It will be understood that the parsing module 205 may generate anitinerary network in any order, allowing itinerary components to beinserted into the itinerary network when a starting/ending referencepoint has been established, such as when the source and destinationitinerary components are identified. An exemplary itinerary network 500is illustrated in FIG. 5 , and is constructed from the natural languagetravel request, “From Toronto to Seattle. From Seattle to Tokyo. Stay atany preferred hotel with a buckwheat pillow. Reservations at Daniel'sBroiler and a well-known sushi restaurant near my hotel in Tokyo.”

Additionally, the following traveler preferences that were received innatural language format include: “Give me lowest cost tickets,” “ExcludeHilton chain,” “Route me through Cincinnati on route to Seattle,”“Integrate my calendar and exclude red category,” as well as many othertraveler preferences, which would be known to one of ordinary skill inthe art with the present disclosure before them.

Additionally, the parsing module 205 may populate each itinerarycomponent with attributes identified by the AI engine 210, such as nodetype and dependencies.

The parsing module 205 may then establish dependencies betweenappropriate itinerary components. There is an extended set ofdependencies that extend from the normal start-start, start-finish,finish-start, and finish-finish to parent-child, local dependency, andso forth. Other exemplary dependencies may include, but are not limitedto: Air-Connect, Local-Connect, Activity, Location, Time, Time andLocation, Logical-Connect, and dependencies that relate to the traveldata of another traveler such as “Travel Together” and “Travel Meet At.”

Time dependencies may be utilized to generate itinerary schedules inreverse order, based upon an end point. For example, using a scheduledmeeting as an end point, the present technology may create and fulfill atravel itinerary for a customer that ensures that the customer arrivesin the proper location and at the proper point in time to allow them toattend the scheduled meeting.

Once node types and dependencies have been established for the itinerarycomponents of the natural language request, the parsing module 205 maygenerate an adjacency matrix using the itinerary components and theirrespective dependencies. Utilizing the adjacency matrix, the parsingmodule may create an itinerary network using the adjacency matrix.

Next, the parsing module 205 may determine a topological ordering ofitinerary components using the itinerary network. It is noteworthy thatthe topological ordering of itinerary components may comprise anarrangement of the itinerary components using their respective locationand time dependencies used by the scheduling module 215 to generate anunconstrained schedule, as will be discussed in greater detail below.

Conceptually, the parsing module 205 and AI engine 210 may utilize theitinerary network to inform the scheduling module 215 in generatingschedules and allocating inventory to the schedules. For example, if anitinerary node includes an activity, or location dependent node such asa theater, restaurant, hotel, conference, or the like, the parsingmodule 205 will understand the activity must take place in a city. Thus,depending on the phraseology encountered by the AI engine 210, the AIengine 210 may loop through the admissible ways of saying “I'm here” andcompare the location against a city dictionary list. If the city isvalid, the AI engine 210 may look for the city name in the itinerarynetwork, creating a node if the AI engine 210 does not find anappropriate node or adding the activity node with a time/locationdependency underneath.

Dependent activities may have their own dependencies as well (forexample, local transportation between a restaurant and a conference).Moreover, preferences associated with each dependent node may appear asanother level of dependency (for example, a buckwheat pillow in a hotelroom).

At each level, the parsing module 205 may check to see if a desired nodeis present in the itinerary network and create nodes as needed. Sinceeach city and activity has a time dependency as well as a locationdependency, in complex itineraries with multiple cities being visitedmultiple times by multiple people, the parsing module 205 may preventconfusion relative to a dependent node's dependencies relative tolocation and time. The parsing module 205 may also inform the consumerthat he has asked for a hotel in a city to which the consumer is nottraveling.

If the parsing module 205 determines a travel phrase or keyword, theparsing module 205 may infer there must be a source and destination anda mode of travel therebetween. The parsing module 205 may further inferwhat kind of travel is most appropriate, so a consumer will not findhimself driving or taking the train from Miami to Manchester, U.K.

The parsing module 205 may not dictate a mode of travel; however, aconsumer may choose to take any form of transportation desired. Theparsing module 205 may send the phrase to the AI engine 210, extract thesource and destination cities, match them against the city listdictionary, and check the network for the nodes existence and add themif necessary. The AI engine 210 may then add the travel node and atravel dependency between the travel node and the two cities to theitinerary network.

Therefore, a consumer may ask for any itinerary, in any order, and thepresent technology may produce a correctly networked schedule. Forexample, the present technology may take the natural language phrase, “Iwant to go from Seattle to Dallas, Miami to Atlanta, Dallas to Miami,Toronto to Seattle.” The parsing module 205 may create an itinerarynetwork which linked Toronto to Seattle to Dallas to Miami to Atlanta.As before, additional content nodes and dependencies may be added asrequired.

The parsing module 205 may understand the different types ofdependencies that occur. For instance, in Toronto there may be anItalian restaurant called Pizza Banfi. If a traveler preferenceindicates a hometown of Toronto, or location-based data from aconsumers' cellphone indicates that the consumer is in Toronto, andconsumer requests “From Pizza Banfi to Seattle,” the AI engine 210 mayunderstand that the consumer requires transport between two points, butthat one point is a city, and the other is a dependent node belonging toanother city. The AI engine 210 may create the Toronto node, place therestaurant as a dependent node, arrange for transport to the airport,which is local dependency, a flight dependency between the two citiesright after it creates the Seattle node.

The scheduling module 215 may be executed to generate an unconstrainedschedule from the itinerary network (e.g., DAG).

The generation of an unconstrained schedule establishes the earlieststart and latest finish for all nodes and hence the initial startingpoint for all requests pertinent to the content represented by thenodes. The scheduling module 215 then employs one of several methods toresolve the allocation of content (e.g., inventory) to the requests forcontent and fill the itinerary.

The scheduling module 215 may apply an Adaptive Method that “levels” theitinerary. For example, the scheduling module 215 may search contentwithin the topological ordering. Each line item in the topology may beconsidered, the exchange searched, and/or offers obtained from thesuppliers. The content request is established by the scheduling module215 from the node type and its attributes as filled out by the parsingmodule 205. These attributes also include general and specificpreferences. A set of valid options may be obtained and ordered by thetraveler preferences.

Further, the scheduling module 215 may employ additional methods toallocate inventory to the request. In a “best alternative” mode, a bestalternative (e.g., available inventory) is selected that comprises thecontent selection that is at the top of the list sorted by travelerpreferences This then sets the starting conditions for successor nodesin the topology and the topology is then recursed by the schedulingmodule 215 using only the best client alternatives. In some instances, aspecific best path itinerary can be identified.

Additionally, the itinerary can be optimized with respect to anequivalence class of airline tickets, where the result from selecting aspecific airline ticket does not impact the remainder of the itinerary.

In an “all possible” mode, each alternative (up to some arbitrary limit)of the sorted list of nodes by client preferences may be considered bythe scheduling module 215 and a separate itinerary developed for each.The scheduling module 215 processes each line item in the topology byapplying a recursion algorithm.

The results of this modal process may generate many differentitineraries whose costs and time frames can vary substantially. Theseitineraries may be sorted in different ways using multiple sortingcriteria; (shortest, lowest cost); (lowest cost, shortest); and soforth. The scheduling module 215 can dynamically schedule robustnessinto the schedule in the sense that it can maintain specific timesrequired between flights; these can be in minutes, hours or days. Thescheduler will automatically extend hotel stays if the flights do notleave on the same day as the hotel checkout.

The scheduling module 215 may create time and space dependent solutionsto the logical schedule dynamically, based on the offers made to therequested itinerary from suppliers. The scheduling module 215 maintainsthe dependencies so that requests remain accurate with respect to thecurrent solution. In this manner, the logistics of travel are maintainedand their constraints adhered to.

The scheduling module 215 may be configured to always return a solution,even if the constraints cannot be met. This solution may comprise theclosest available under the constraints and options that have beenrequested. It is noteworthy that when inventories for content are tight,it could take an extremely long time to find any solution. Therefore an“approximate fit” schedule may be preferred to no schedule.

The scheduling module 215 may be configured to generate a leveledsolution where the scheduling module 215 may allow requests to level outin time across the itinerary, showing when solutions are available.Thus, if a customer books a flight today to San Francisco, thescheduling module 215 may allow a solution for tomorrow if that is theonly alternative.

The scheduling module 215 may also provide one or more possibleschedules (solutions) to the exchange 105 (FIG. 1 ) in either asequential or leveled manner. In the sequential method, all dependenciesfor a specific aspect of the itinerary may be filled before it issubmitted to the exchange 105. An alternative method allows thescheduling module 215 to maintain the times and dates specified, andonly offers that match these times and dates are allowed.

Referring now to FIGS. 2 and 6 collectively, the scheduling module 215may transmit itinerary components and/or entire itinerary schedules(such as the itinerary network) to the exchange 105. The exchange 105may employ a listener that immediately picks up the new requested lineitem or itinerary (Step 605). Line items or an itinerary may also bereferred to as a “request.” The listener may identify the itinerarycomponents (nodes) (Step 610) and/or a buyer profile or content profileassociated with the itinerary (Step 615). The listener may compose alist of the suppliers that have indicated that they want to bid on thesetypes of line items or itineraries (Step 620). Suppliers may be notifiedof these requests and can then analyze them and bid on them or entireitinerary (Step 625). The transactions made available to the supplierscontain the entire content, inferential information, and/or semantics ofthe request together with a framework for interpreting the same. Thesupplier can respond based on review of its inventory and availability.In other instances, the supplier can dynamically decide what to do withthe content and price through its own legacy systems. Alternatively, theexchange 105 makes available APIs to interrogate the system for anyrequests that the supplier may want to look at (For example, City-Pairfor flights and/or Activity Keyword or partial Keyword). In someembodiments, the default listener is the exchange itself that willprocess, search, and respond to every request.

Offers may be written back to the exchange in the form of a response.Additionally, suppliers can respond with any additional content theydesire, together with pricing for itinerary components. For example, anairline can offer a golf bag at $100 with the air ticket at a reducedprice. Other similar types of vouchers may be exchanged or facilitatedutilizing the present technology.

As offers are written to the exchange 105, they are matched against theline items and itinerary generated by the scheduling module 215. In someinstances, before being considered, the offers may be passed through aset of filters that describe the traveler's restrictions andpreferences. An exemplary flow diagram of a process 600 for fulfilling aschedule (e.g., request) is depicted in FIG. 6 .

According to some embodiments, the scheduling module 215 may selectivelyadjust the allocation of inventory based upon various constraints suchas available/dynamic inventory. In other embodiments, the schedulingmodule 215 may adjust the schedule provided to the consumer based uponinferential modeling of the consumer's request (for example, when theconsumer expresses a traveler preference that is new or contradictory toa known traveler preference for that particular consumer).

According to some embodiments, the modification module 220 may beexecuted to process modifications to travel itineraries. Generallyspeaking, the modification module 220 may receive a modification to thetravel itinerary from a traveler who has previously input a naturallanguage travel request that has been processed using the aforementionedmethods to generate an itinerary schedule.

The modification module 220 may adjust the allocation of availableinventory for each itinerary component remaining in the travel itinerarybased upon one or more dependency adjustments associated with theplurality of nodes and the plurality of edges and caused by modificationof the travel itinerary. That is, because the parsing module 205appreciates the dependencies between the current itinerary components inthe schedule, along with the dependencies of the modification, theparsing module 205 may insert the modification into the schedule andadjust other itinerary components, as necessary. Therefore, even for anitinerary that is currently being executed (e.g., traveler has alreadycompleted at least a portion of their itinerary), the parsing module 205may adjust the schedule to ensure that traveler preferences aremaintained. For example, if cost is an important traveler preference,the parsing module 205 may adjust the schedule to cause the least impactfrom a cost perspective.

The parser trees may define a priori AI engine that can deal with anyconversation seeking to build or change itineraries through successiveiterations of the conversation—all in place before the first everconversation takes place. Furthermore, no rules are required; rather,the understanding is fundamental and complete in advance of theconversations or requests with users.

The itinerary network may handle the language interface between the userand the system. The itinerary network also facilitate interactionsbetween various elements of the system itself. The network nodes may becomprised of tokens. The paths (sequence of tokens) in the itinerarynetwork are called ‘phrases’. Together, the tokens and the phrases maymake a normalized travel language or meta language. This is strictly apattern (or phrase) recognition process; no traditional linguisticgrammars are used in this process. This is a departure from traditionalNatural Language Processing methods which rely heavily on the linguisticsyntactic composition of a sentence and data to learn relationshipsbetween the various syntactic elements. The system is able to constructthe phrases without ever having to have experienced them.

Tokens are the categorization of information related to travel. Forexample, the tokens may include travel attributes related to the travelrequest, such as passengers, source and destination cities, times anddates, time and date restrictions, hotel names, addresses, and otherdescriptive elements, such as dependencies between the various itinerarynetwork elements. A phrase is an ordered set (or sequence) of tokensthat describes an intention, request, or like communication with thesystem (parser). In effect, the entire conversation related to theitinerary may be pre-defined in this manner. All travel conversationsand their intent, regardless of context, and the like, can be reduced toa normalized set of phrases in the parser trees.

FIG. 7 shows an itinerary network 700, according to an exampleembodiment. The itinerary network 700 may include nodes 705 and edges710. FIG. 8 shows a sub-path of nodes of an example itinerary network800. The nodes may have annotations. A node 805 may have an annotation810, and a node 815 may have an annotation 820. Each node in theitinerary network 700 or 800 can have one or more annotations 810 and820 associated with it. The annotations 810 and 820 may describespecific information or understanding. For example, the node 805 mayhave the annotation 810 ‘flight’. This annotation may mean that there issufficient information (within the path or network subtree reaching thenode 805) to determine that there is an intentional request for aflight. The AI engine understands this information together with thedata associated with the flight. Another sub-path may add additionalinformation to an existing node or define a global requirement orpreference or a change to the existing itinerary network. As thesetokens from the conversation are processed (for this example, insequence), the sequence may be matched against a sub-path in the parsertree.

The system may be configured to perform error handling and the abilityto anticipate “next” likely token(s). Specifically, at any stage inmatching the ordered set of tokens obtained from the request, the parseralready knows the set of next possible valid tokens of the travelrequest. This is significant because the parser can detect insufficientinformation to fully understand a request, as well as missinginformation (tokens) necessary for generating the travel itinerary.Based on the possible next tokens, the system may detect insufficientinformation associated with the travel request and request theinsufficient information from the user.

An example of building a set of phrases using the parser trees. Once amatch for a sub-path with an annotation is obtained, there is created animmediate and absolute “understanding” and a potential actionable event.The nodes in the sub-path may not have any physical resemblance to whatwas understood or inferred or the actionability thereof. Thisconstitutes an a priori AI engine. The a priori AI engine hasunderstanding before there is any specific request and is general innature, and the a priori AI engine requires no data for thisunderstanding; rather, it can handle any such request associated withthe sub-path. Indeed, the capabilities of the itinerary network andscheduler define the phrases in their totality. Additional phrases, whenencountered, merely constitute an equivalence class relationship with analready extant phrase.

For example, as shown on FIG. 8 , at the stage B, the node 805 may havethe attribution of a flight that means that the parser hasintentionality to define a flight. At stage C, the node 815 may have theattribution of a flight that means that the parser has intentionality todefine a hotel. The system understands that what is requested is aflight and a hotel. The set of nodes leading up to this providessufficient and necessary logical information to create a flight. Now anactionable phrase may start. This phrase invokes an action, for example,called “Build Flight and Hotel.” This action builds a travel itineraryand the itinerary network, which represents the travel itinerary in aunique manner. To build the itinerary network, the system determinescontent nodes, city nodes, city children content, the relationshipsbetween the nodes, the dependencies between nodes, the ability torepresent multiple travelers, and so forth.

The Parser Complexity Class. The cardinality of the set of equivalenceclasses is finite, countable, and has N members. This set may form acompact cover of the set of actions, requests, information, and so forthdefined by the system. The equivalence classes, which provide equivalentways of stating any phrase, form a larger open cover 905 as shown onFIG. 9 and discussed below. The complexity class of the a priori enginemay be <O(kN), where N is the finite number of equivalence classes(i.e., the finite number of statements about the travel itinerarypossible to be made) and k is the maximum number of the equivalenceclasses of the statements. This holds true regardless of how many timesphrases are matched in the parser trees or the size of the context inwhich they are made.

FIG. 9 shows a parser network 900 as a cover for travel conversations,according to an example embodiment. While the normalized set of phrasesform a compact cover 910 of the intentionality space for travel, eachphrase can have a set of like phrases that are equivalent to the singlemember phrase of the compact set and form an open cover 905. Forexample, “I want to go from YYZ to MIA” is equivalent to “I want to goto MIA from YYZ”. While the set of phrases is O(N) complexity class, thecompact cover 910 together with the equivalence classes form acomplexity class of O(kN). This is extremely important since most otherAI technologies are essentially NP-complete.

Building the Itinerary Network. The natural language request of the usermay have the following form: “I want to fly from Toronto to New Yorkstaying 3 days upper west side in a 5 star hotel then go to Miamistaying in South Beach for 2 nights then to San Francisco staying at theSofitel on Twin Dolphin drive for 2 nights then home. Business classtickets on all flights. Jonathan will join me in San Francisco stay atthe same hotel and we will share a room. He will then go to Seattle stayat the Woodmark Hotel in Kirkland for 3 days then fly home.” The requestmay be processed into meta patterns (phrases) and these phrases may beused to build a directed, acyclic, path connected network, which in turnmay be used to build a resource independent (logical and resourceunconstrained) schedule.

The goal of the system includes finding suitable content for thisitinerary as defined by the itinerary network. The itinerary network mayprovide the context both when constructing the itinerary network forrequests from the conversation, as well as when creating the goal forthe system, namely, to fulfill this travel itinerary network. In thismanner, travel requests and successive requests may define the itinerarynetwork and the system may always act to fulfill the itinerary network,whether by creating a new itinerary network or changing an existingitinerary network. This iterative process can continue indefinitelywithout human intervention. The system may be automatically goal seekingand the AI engine may be synthetic and analytic a priori (i.e., no dataand/or experience may be required for the AI engine).

An example itinerary network 1000 is shown in FIG. 10 . The itinerarynetwork 1000 may have a plurality of nodes 1005, 1010, 1015 associatedwith flights, hotels, cities, and so forth, and a plurality of edges1020, 1025 that connect the nodes.

Properties of the Itinerary Network. The AI engine may consequently dealwith multiple states that occur over the lifespan of the travelitinerary. The AI engine also understands the properties of an itineraryobject. For example, the AI engine may understand that the itineraryobject is a compact path connected topological space. When the pathconnectedness property is broken, the AI engine understands theimplications of this and how to deal with it by communicating with theuser. This understanding is naturally inherent to the AI engine and themethods of the present disclosure.

The itinerary network may provide a coherent consistent entity that canbe treated by the scheduler with a single set of methods and provide ascheduling AI ecosystem for the scheduling of the travel request. The AIengine is aware of the context of the travel itinerary, namely a stage,state, and all the methods and attributes the itinerary networkrepresents. The resultant itinerary network contains all the informationnecessary for the system to supply congruent content (logistic andcurated data). The characteristics of the itinerary are that of apath-connected, directed acyclic, compact topological space, orcombinations of such spaces. This provides the capability of schedulingthe itinerary in a coherent manner and allows the parser to understandall the aspects of an itinerary with respect to nodes of the itinerarynetwork.

The Construction of Parser Network Trees. Normally, one considersnatural language as the mechanism to interface with a user and themachine. Natural language parsing is complicated and requires correctlinguistic grammar to interpret the request. This is difficult enoughand subject to the ambiguities of language, as well as because people donot often speak grammatically correctly. Regardless of the ability forthe natural language parsing to parse a request into a grammaticalstructure (subject, objects, verb, clauses, etc.), the ability for thesystem to actually understand the context and intent of the spoken wordis complex. Traditional methods for AI use language through inferenceand large amounts of data (experiential) to determine what the intentactually is. Complex statistical methods in the end just giveprobabilities that the spoken sentence means a specific thing. Forexample, in conventional natural language parsing systems, in responseto “I want to fly to Montreal next Tuesday” the conventional naturallanguage parsing system replies, “There is a 94% likelihood that youwant to take a flight to Montreal next Tuesday.” Furthermore, no contextof the conversation is determined by the conventional natural languageparsing system.

Building a priori parser tree(s). The parsing may be fully integratedinto the system, methods, and all the conversations that exist betweenthe modules of the system, the state, and stage of the itinerary, theerror conditions together with the conversations that may exist betweenthe user and the system.

The a priori engine may be, in fact, built in reverse order to thetraditional model. All the goal seeking methods may be defined, givencontext in terms of the itinerary object, and then the specific phrases(meta language) may be defined in these terms. The a priori engine mayinclude the itinerary network, the parser network and the phrases andthe lexicon required to drive them. The set of phrases may be a compactcover of the truthful statements that can be made within the tautologyof the a priori engine. The AI engine can be easily extended to covernew methods, lexicon, and phrases, without experimentation or any datasources.

Since the AI engine has to be constructed from known structures andmethods, the AI engine cannot be learned via experience or data model.The a priori engine may comprise a set of phrases which are understoodexplicitly in terms of their respective goals/objectives, informationcontent, queries, and the like. The phrases are understood in context ofthe current state of the itinerary, supply chain, and so forth.

Embodiments of a computing system discussed herein include providing endto end digital service, where the AI engine extends throughunderstanding of a request from a user, the goal seeking properties ofconstructing a congruent itinerary, modifying the itinerary, curatingthe content for each user, maintaining context and sentience, andseeking to complete goals.

The AI engine discussed herein can be implemented via aspecially-programmed and special-purpose computer. The computing enginemay utilize one or more processors storing instructions, static and/ordynamic memory, one or more databases or other data structures, andnetwork interface(s).

FIG. 11 illustrates an exemplary computing system 1100 that may be usedto implement an embodiment of the present technology. The system 1100 ofFIG. 11 may be implemented in the contexts of the likes of computingsystems, networks, exchanges, servers, or combinations thereof disclosedherein. The computing system 1100 of FIG. 11 includes one or moreprocessors 1110 and main memory 1120. Main memory 1120 stores, in part,instructions and data for execution by processor 1110. Main memory 1120may store the executable code when in operation. The system 1100 of FIG.11 further includes a mass storage device 1130, portable storage mediumdrive(s) 1140, output devices 1150, user input devices 1160, a graphicsdisplay 1170, and peripheral devices 1180.

The components shown in FIG. 11 are depicted as being connected via asingle bus 1190. The components may be connected through one or moredata transport means. Processor unit 1110 and main memory 1120 may beconnected via a local microprocessor bus, and the mass storage device1130, peripheral device(s) 1180, portable storage device 1140, anddisplay system 1170 may be connected via one or more input/output (I/O)buses.

Mass storage device 1130, which may be implemented with a magnetic diskdrive or an optical disk drive, is a non-volatile storage device forstoring data and instructions for use by processor unit 1110. Massstorage device 1130 may store the system software for implementingembodiments of the present technology for purposes of loading thatsoftware into main memory 1120.

Portable storage device 1140 operates in conjunction with a portablenon-volatile storage medium, such as a floppy disk, compact disk (CD),digital video disc (DVD), or USB storage device, to input and outputdata and code to and from the computer system 1100 of FIG. 11 . Thesystem software for implementing embodiments of the present technologymay be stored on such a portable medium and input to the computer system1100 via the portable storage device 1140.

Input devices 1160 provide a portion of a user interface. Input devices1160 may include an alphanumeric keypad, such as a keyboard, forinputting alphanumeric and other information, or a pointing device, suchas a mouse, a trackball, stylus, or cursor direction keys, or voice totext. Additionally, the system 1100 as shown in FIG. 11 includes outputdevices 1150. Suitable output devices include speakers, printers,network interfaces, and monitors.

Display system 1170 may include a liquid crystal display (LCD) or othersuitable display device. Display system 1170 receives textual andgraphical information and processes the information for output to thedisplay device.

Peripherals devices 1180 may include any type of computer support deviceto add additional functionality to the computer system. Peripheraldevice(s) 1180 may include a modem or a router.

The components provided in the computer system 1100 of FIG. 11 are thosetypically found in computer systems that may be suitable for use withembodiments of the present technology and are intended to represent abroad category of such computer components that are well known in theart. Thus, the computer system 1100 of FIG. 11 may be a personalcomputer, hand held computing system, telephone, mobile computingsystem, workstation, server, minicomputer, mainframe computer, or anyother computing system. The computer may also include different busconfigurations, networked platforms, multi-processor platforms, and soforth. Various operating systems may be used including Unix, Linux,Windows, Macintosh OS, Palm OS, Android, iPhone OS and other suitableoperating systems.

It is noteworthy that any hardware platform suitable for performing theprocessing described herein is suitable for use with the technology.Computer-readable storage media refer to any medium or media thatparticipate in providing instructions to a central processing unit(CPU), a processor, a microcontroller, or the like. Such media may takeforms including, but not limited to, non-volatile and volatile mediasuch as optical or magnetic disks and dynamic memory, respectively.Common forms of computer-readable storage media include a floppy disk, aflexible disk, a hard disk, magnetic tape, any other magnetic storagemedium, a CD-ROM disk, DVD, any other optical storage medium, RAM, PROM,EPROM, a FLASHEPROM, any other memory chip or cartridge.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. The descriptions are not intended to limit the scope of thetechnology to the particular forms set forth herein. Thus, the breadthand scope of a preferred embodiment should not be limited by any of theabove-described exemplary embodiments. It should be understood that theabove description is illustrative and not restrictive. To the contrary,the present descriptions are intended to cover such alternatives,modifications, and equivalents as may be included within the spirit andscope of the technology as defined by the appended claims and otherwiseappreciated by one of ordinary skill in the art. The scope of thetechnology should, therefore, be determined not with reference to theabove description, but instead should be determined with reference tothe appended claims along with their full scope of equivalents.

What is claimed is:
 1. A system for fulfilling travel requests, thesystem comprising: a network of travel content suppliers for providing:supplier-defined record types; and travel content records; a contentdatabase for storing the travel content records; a metadata database forstoring the supplier-defined record types; a parsing module configuredto: receive a travel itinerary request from an exchange; in response tothe travel itinerary request, determine associated travel componentsexpressed as metadata records and equivalence classes assembled asitinerary networks; an artificial intelligence engine configured toimpose a structure of travel logistics on the travel itinerary request,the artificial intelligence engine comprising: a pattern recognitionmodule for determining a pattern of the metadata records and theequivalence classes; and a scheduling module configured to: receive theitinerary networks; search the content database to retrieve itineraryobjects; level the itinerary networks to select a subset of theitinerary objects; and return the subset of the itinerary objects to thenetwork of travel content suppliers.
 2. The system of claim 1, whereinthe scheduling module is further configured to generate a constraineditinerary network based upon the subset of the itinerary objects.
 3. Thesystem of claim 2, wherein the scheduling module is further configuredto return the constrained itinerary network to the network of travelcontent suppliers.
 4. The system of claim 1, wherein each of theitinerary networks is associated with at least one of a stage, a stateor a context.
 5. The system of claim 1, wherein the itinerary networksare expressed as directed acyclic graphs.
 6. The system of claim 1,wherein the supplier-defined record types and the travel content recordsare provided via an application programming interface.
 7. The system ofclaim 1, wherein the returning the subset of the itinerary objects tothe network of travel content suppliers comprises returning the subsetof the itinerary objects via the exchange, wherein the exchange employsa listener configured to identify the itinerary objects associated withthe travel request.
 8. The system of claim 1, wherein the returning thesubset of the itinerary objects to the network of travel contentsuppliers comprises returning the subset of the itinerary objects viathe exchange to a subset of the travel content suppliers within thenetwork of travel content suppliers, the subset of the travel contentsuppliers identified by the exchange based on the subset of theitinerary objects, wherein the exchange employs a listener configured toidentify the itinerary objects associated with the travel request. 9.The system of claim 1, wherein the returning the subset of the itineraryobjects to the network of travel content suppliers comprises writing anoffer expressed as a response.
 10. The system of claim 9 wherein thenetwork of travel content suppliers is configured to, in response toreceiving the offer, provide a pricing for the subset of the itineraryobjects.
 11. The system of claim 10, wherein the network of travelcontent suppliers is further configured to provide additional contentrelating to the offer.